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CLIENT PROFILE MANAGEMENT WITHIN A MARKETING SYSTEM 

TECHNICAL FIELD 

The present invention relates generally to telecommunication 
5 systems and, more particularly, to client profile management in a marketing 
system. 

BACKGROUND OF THE INVENTION 

Telemarketing, direct mail and direct sales have become more 
widespread in recent years. A diversity of businesses are employing marketing 

10 to sell their goods and services. One of the goals of such marketing is to 
establish new customers so as to expand the customer base of a business. These 
businesses desire to target potential customers who are most likely to be 
effectively solicited by marketing campaigns and contacts. 

Conventional systems identify potential customers for contact by 

15 telephone numbers or addresses. In general, batches of telephone numbers or 
addresses are placed on contact lists and mass calling mailing or visiting 
campaigns are performed. Unfortunately, such mass campaigns are not very 
effective in that they generally have high failure rates. In addition, such 
campaigns utilize a large volume of resources. 

20 SUMMARY OF THE INVENTION 

The present invention provides a more effective approach to 
marketing campaigns and contacts. The present invention focuses on a client 
profile management system that is part of a larger marketing system. The client 
profile management system maintains a database of client profiles. The client 

25 profiles may include individuals or businesses. The profiles are maintained, not 
on a per telephone or address basis, but rather on a per individual basis. As such, 
separate client profiles may be maintained for two individuals that live at die 
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same address and share a common phone number. In addition, the client profiles 
may be updated to reflect changes in a client, such as telephone number changes, 
name changes, and address changes. The client profiles may be received as input 
for the client profile database in a number of different formats. The client profile 
5 management system provides mechanisms for parsing and formatting such input 
into a standardized format that is acceptable to the database. 

In accordance with a first aspect of the present invention, a method 
is practiced in a computer system that has a database for holding client profiles. 
Each client profile holds information regarding clients for marketing contacts. In 

10 this method, input data that holds data about a client is received from a data 
provider for possible addition to the database. Matching rules are applied to 
determine whether die input data is for a selected client that already has a client 
profile in die database. The matching rules compare any name information and 
any address information in die input data with any name information and any 

15 address information in the client profile for the selected client. If it is determined 
by the matching rules that die input data is not for a selected client that already 
has a client profile in die database, a new client profile is created for die selected 
client in the database to hold data from the input data. On the other hand, if it is 
determined by the matching rules that the input data is for a selected client that 

20 already has a client profile in die databases, overlay rules are applied to 
determine how to update the client profile in view of the input data. The client 
profile is then updated 

In accordance with another aspect of the present invention, a first 
client profile for a first client at a given telephone number is stored in a database. 

25 The database stores client profiles for the marketing contact such that each client 
profile stores information regarding a client. A second client profile for a second 
client at die given telephone number is also stored in the database. The database 
has an index for accessing the client profiles on a per client basis. Thus, separate 
client profiles are provided for a single phone number in the database. 
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In accordance with a further aspect of the present invention, a first 
address is stored in the database for a selected client in the client profile. The 
database stores client profiles for maiketing contact A second informational or 
former address for die selected client is stored in the client profile as well. In 
5 response to a request from a requester, one of the addresses stored in the client 
profile is provided to the requester. Hence, the database stores multiple 
addresses for a single client 

In accordance with an additional aspect of the present invention, a 
first set of input data is received in a first format from a first data provider at a 
10 computer system. The computer system holds a database that has client profiles 
for holding information regarding clients for marketing contact The first set of 
data is reformatted into a standardized format and at least some of the data in the 
first set of input data is added to a first client profile in the database. A second 
set of input data and a second format is received from a second data profile at the 
15 computer system. The second set of input data is reformatted into the 
s tan d ardiz ed format and at least some of the data in die second set of input data 
is added to a second client profile in die database. The computer system includes 
the ability to receive and integrate data from multiple data providers in different 
data formats. 

20 BRIEF DESCRIPTION OF THE DRAWINGS 

A preferred embodiment of the present invention will be described 
below relative to the following drawings. 

Figure 1 is a block diagram illustrating the strategic marketing 
(SaMS) infrastructure that is suitable for practicing the preferred embodiment of 
25 the present invention. 

Figure 2 is a block diagram of a computer system that is suitable 
for practicing die preferred embodiment of the present invention. 
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Figure 3 illustrates the logical organization of the CARMA 

database. 

Figure 4 illustrates data flow within CARMA. 
Figure 5 is a flowchart illustrating the steps that are performed to 
5 process data by CARMA. 

Figure 6 is a flowchart illustrating the steps that are performed to 
apply the matching rules. 

Figure 7 is a diagram that illustrates the different categories of rules 
that are found within the match rule table. 
10 Figure 8 is a diagram that illustrates the different types of overlay 

rules that are found in the preferred embodiment of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

The preferred embodiment of the present invention provides a 
client acquisition and retention management architecture (CARMA). CARMA is 

15 part of a strategic marketing system (SaMS) infrastructure that provides client 
management information management and contact services for a marketing 
system. CARMA collects, tracks, and manages client information for marketing 
and sales functions. CARMA is flexible enough to be used by virtually any type 
of business and can track a wide range of information regarding clients. 

20 Information regarding the clients may be obtained from virtually any source in 
any format CARMA provides processing for standardizing data formats and 
performing hygiene functions on input data. 

As will be described in more detail below, CARMA includes a 
database of client profiles and program code for managing the client profiles. 

25 CARMA receives input data from multiple sources and processes the input data 
to create new client profile records in die database. In addition, CARMA 
determines whether input data is received for a client that already has an 
associated client record within the database. CARMA provides matching 



WO 98/49640 



5 



PCT/US98/06448 



techniques for locating such matches and provides overlay rules for resolving 
how the existing client profile should be updated 

The client profiles are created on a per individual basis rather than 
on a per telephone basis or a per address basis. Multiple clients may share a 
5 common telephone number or address. Profiling information and characteristics 
is, thus, applied to individuals rather than to an entire household. CARMA also 
may m a intain multiple relationships per client, including multiple addresses, 
multiple account numbers, multiple membership numbers, multiple input source 
(list) entries and multiple phone numbers per client CARMA facilitates changes 

10 in client profiles by performing continuous ongoing tracking of clients. Address 
changes, telephone number changes, name changes, service connections and 
service disconnections may be tracked via CARMA. 

Figure 1 is a block diagram illustrating die SaMS infrastructure 10. 
The SaMS infrastructure 10 includes CARMA 12 and data providers 14. The 

15 data providers 14 provide input data to CARMA 12 that is processed for 
integration into the client database maintained by CARMA. The input data may 
originate from external data sources 16 that originate outside the SaMS 
infrastructure 10 and internal data sources 18 that reside within the infrastructure. 
The SaMS infrastructure 10 also includes a decision support system (DSS), 

20 which is a large-scale data warehouse that includes programs for collecting, 
storing, managing, distributing, and analyzing data. Data from the data providers 
14 is also passed to DSS 20 for integration into the data warehouse. CARMA 12 
interacts with DSS 20 in that updates to client profiles are passed by CARMA 12 
to DSS 20 in a generalized format 

25 DSS 20 collects data from the data providers 14 where client 

identification is not a concern. Such data may include, for example, the number 
of people who move between a given pair of states, the number of people who 
purchase both a car and home stereo in the same year, or the number of women 
who own a business and are members of a political party. The data collected by 
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DSS 20 varies according to business needs of users of the SaMS infrastructure 
10. DSS 20 provides access to this data by business strategy units (BSU) 22. A 
BSU is a company's organization that is responsible for formulating business, 
marketing, and sales strategy. Each BSU performs strategic queries of data in the 
5 data warehouse of DSS 20 using analytical tools provided by DSS. The results 
of these queries are used by the BSUs 22 to formulate marketing campaigns. 

The SaMS infrastructure 10 also includes a contact infrastructure 
(CONI) 24. CONI 24 is a software system that uses data extracted from the data 
warehouse along with specific strategies from the business strategy units 22 to 

10 generate leads that marketing personnel may use. These leads are deposited 
within a centralized lead repository (CLR) 26. The business strategy units 22 
specify criteria to CONI that CONI is to use in extracting lead data from DSS 20. 
The lead data identifies client leads (/.e., potential customers who are to be 
targeted in a marketing campaign). Client leads are identified by a client 

15 identifier that is stored in DSS 20. CONI 24 generates leads by matching these 
client identifiers with a name, address and/or telephone number that are obtained 
from CARMA 12. CONI is described in more detail in copending application 
entitled, "SYSTEM AND METHOD FOR AUTOMATED LEAD 
GENERATION AND CLIENT CONTACT MANAGEMENT FOR A SALES 

20 AND MARKETING PLATFORM," which was filed on even data herewith, 
which is assigned to a common assignee with the present application and which 
is explicitly incorporated by reference herein. 

The leads that are generated by CONI 24 and stored in the CLR 26 
are distributed to one or more telemarketing/direct mail centers (TM/DM 

25 Centers) 28. These centers may include call centers from which telemarketing 
agents perform client contact sales and services over the telephone. These 
centers may also include direct mail campaign facilities. The agents at the 
TM/DM center 28 use the leads provided via CLR 26 and store the results of 
contacts made using the leads in the CLR. These results may be fed back to both 



WO 98/49640 



7 



PCT/US98/06448 



CARMA 12 and DSS 20. When an agent at one of the TM/DM Centers 28 
succeeds in signing up a new customer or making a sale, the order may be 
entered in the customer order entry system 30. The customer order entry system 
records the order and provisions the order. The customer order entry system 30 
5 also updates DSS 20 to indicate the results of the order. If the order is for long 
distance service, the order is passed to a national local exchange carrier (LEC) 
interface system (NLIS) and quick PIC system 32. These systems 32 pass the 
order to the client's LEC 34 so that the LEC can convert the client's PIC at the 
local class 5 switch. 

10 The SaMS infrastructure 10 is described in more detail in 

copending application entitled "SYSTEM AND METHOD FOR AUTOMATED 
LEAD GENERATION AND CLIENT CONTACT MANAGEMENT FOR A 
SALES AND MARKETING PLATFORM," which was filed on even date 
herewith, which is assigned to a common assignee with the present application 

15 and which is explicitly incorporated by reference herein. 

CARMA 12 may be run on a number of different types of 
computer systems. Figure 2 is a block diagram illustrating a computer system 40 
that is suitable for running CARMA 12. A mid-range computer that employs the 
DEC Alpha processor from Digital Equipment Corporation of Maynard, 

20 Massachusetts, is suitable for running CARMA 12. Computer system 40 
includes a central processing unit (CPU) 42 that is responsible for overseeing 
operation of the computer system. The CPU may include a number of peripheral 
devices, such as a video display 44 and an input device 46. The computer system 
40 may also include a network adapter 48 for interfacing the computer system 

25 with a local area network. A modem 50 may be provided in the computer system 
40 to facilitate communications with remote computing resources over 
conventional telephone lines. The computer system 40 may include a number of 
different types of storage 52, including primary storage and secondary storage. 
The storage 52 holds a client database 56 and a copy of the program code 54 for 
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CARMA. Those skilled in the art will appreciate that the computer system 40 
may be alternatively a multiprocessor system or a distributed system. The 
present invention is not limited to being practiced on a single processor system. 

The client database 56 has a logical architecture like that depicted 
5 in Figure 3. The client database 56 contains a number of different tables, where 
each table contains different information regarding a client Each client is 
assigned a unique client identifier (client_id). This client identifier links 
information that is kept in the different tables about the client The linked 
records for a client in aggregate, constitute the client profile for the client The 

10 three primary tables in the client database 56 are the client table 60, the address 
table 82, and the domestic phone table 90. Each record in the client table 60 
contains information about a client, such as client ID, social security number, 
name, and professional title. The address table 82 holds information about the 
client's address, whereas the domestic phone table 90 holds information 

15 regarding a client's phone number and phone service. 

It should be appreciated that there may be a one to many 
relationship between the client table 60 and the address table 82, as well as 
between the client table 60 and the domestic phone table 90. A client may have 
multiple addresses and multiple phone numbers associated with it Each of the 

20 addresses has a separate record in the client address table 80 and each of the 
domestic phone numbers has a separate record in the domestic phase table 90. 
The client table 60 and the address table 82 are linked by an intermediate table: 
the client address table 80. Each address of a client has a record in the client 
address table 80 that is linked to the client table 60 by "clntjd**. Each address 

25 has a status indicator ("adrstat") within die client address table 80. The address 
status indicator may have a value of "active,** "obsolete** or "informational.** 
This status indicator is useful in tracking a client as a client moves among 
addresses. An address identifier ("adr Jd") is held in the client address table to 
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link the record and the client address table to the address record in the address 
table 82. 

The client phone table 76 serves as an intermediate table between 
the client table 60 and die domestic phone table 90. For each phone number or 
5 client, the client phone table 76 contains a phone number in three fields: "npa," 
"nxx," and "line." 

Suppression tables are also provided for the intermediate tables 
(e.g. 9 die client address table 80 and the client phone table 76). In particular, the 
client address supp table 84 holds suppression information regarding a client 
10 address. Similarly, the client phone supp table 88 holds suppression information 
regarding a client phone number. The phone supp table 92 holds suppression 
information regarding records stored within the domestic phone table 90. 
Analogously, die address supp table 88 holds suppression information for records 
stored in die address table 82. Household enhancement information is stored 
15 within die address enhancement table 86. Enhancement information for clients 
may be stored in die client enhancement table 74. 

A client account table 66 tracks internal account numbers for die 
client There may be a one to many relationship between die client table 60 and 
the client account table 66. In other words, information about multiple accounts 
20 may be stored for a given client. 

A client member table 70 tracks a client's memberships in affiliate 
clubs, affinity clubs, and various other clubs. Examples include airline frequent 
flyer clubs, professional organizations, auto clubs, credit cards, travel clubs, 
health clubs, and the like. There may be relationships between records in die 
25 client member table 70 and records in die client table 60. 

The client prov detail table 72 holds detailed audit information 
regarding the data provider, such as a client's phone, address, and name as 
provided by each source. The client enhancement table 74 holds enhancement 
information regarding clients. The client language table 78 holds information 
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regarding the natural language that the client speaks and/or understands. 
Multiple client language records may be provided for a single client The client 
list table 62 serves as an intermediate table for linking a client as identified by a 
client identifier with a list record in the list table 61 which defines all sources 
5 (lists) by which a client has been received. 

As was mentioned above, CARMA 12 is able to process input data 
for multiple data sources and to update die data in the client database 56 
accordingly. This process of handling new input data will be described below 
relative to Figures 4 and 5. New input data is processed in load transactions. 

10 Initially, the raw input data is received at CARMA 12 from the data providers 14 
(step 120 in Figure 5). As was mentioned above, die data providers may be both 
external and internal and may provide a variety of different types of information. 
A scheduler 100 is responsible for invoking the respective stages of processing 
performed by CARMA 12. The scheduler initiates and monitors the data load 

15 process upon receipt of the data. The scheduler initially causes formatting and 
data hygiene to be performed on the raw input data (step 122 in Figure 5). This 
formatting and data hygiene is performed by a stage load process 102 (Figure 4). 
The stage load process 102 performs standardization of names and addresses of 
clients. The stage load process ensures that client identification (in the form of a 

20 name, social security number, or other common identifier) is valid and that 
certain information, such as mailing address, is valid and in a proper format. 

In the preferred embodiment of die present invention, CARMA 12 
uses the PostalSoft's TrueName product 104 and the ACE product 105. 
Mapping mechanism 103 determines which of the products 104 and 105 should 

25 be uxsed on input data. PostalSoft 104 standardizes, parses, corrects, translates, 
appends, and validates name/address information in the data input from die data 
providers 14. In general, PostalSoft parses all billing names and address 
information into standard name and address database attributes. ACE 305 also 
performs standard billing address append functionalities, such as the 
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identification and attachment of full nine digit zip codes, cany routes, geographic 
match codes and check digits for bar-coding. Street suffix values unit 
designators are also standardized by TrueName. TrueName 104 maintains a 
reference list of first names and associates a gender code with each first name 
5 (/.e., male, female). 

The preferred embodiment of the present invention also includes a 
number of custom coded edits or translations 106 that embellish the PostalSoft 
product 104. For example, the name information is always placed at the 
beginning of the output Invalid characters are not permitted in names and extra 

10 blanks are eliminated in names and addresses. Literals such as "in care or or 
"attention of* are deleted Repeated names within first name fields and last name 
fields are deleted. Invalid names are eliminated. This may include the 
elimination of profanity and repetitive characters. The name components of 
input are removed if the hygiene score is below a predefined threshold value. 

15 Stage load process 102 outputs the validated standardized data to 

an interim data store 108. This enables a user to view and approve the data using 
the computer system 40 before the data is passed on to a final load process 1 10. 
The final load process 110 performs some additional processing of the data 
before data is added to the client database 56. 

20 The final load process 110 entails applying client matching 

algorithms 1 12. These client matching algorithms 1 12 are applied to determine if 
the client identification information that is provided and the data matches an 
existing client in the client database (step 124 in Figure 5). Figure 6 is a flow 
chart illustrating in more detail how the client matching rules are applied. First, 

25 critical matching criteria is examined for records in the client database 56 and 
information contained in the input data. Values that indicate the matching 
condition for each of a number of different criteria are assigned (see step 134 in 
Figure 6). 
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The critical matching criteria include a social security number 
matching (SSN) criteria 19. The value for the social security number matching 
criteria may be "Y", indicating that Acre is a match and that both die input data 
and the record in the client database 56 include a populated social security field. 
5 The value may also be "N" indicating that there is no match but that the input 
data and the database record include a social security number value. The value 
may lastly be "B", indicating that one or both of the input data or the database 
record do not contain a social security number value. 

Last names are compared to determine a value for a last name 
10 match (LNM) matching criteria. A value of **Y" for the LNM criteria indicates 
an exact match excluding spaces and special characters, identified misspellings, 
and hyphenated last names for married women. A value of "1ST indicates no 
match and that a last name is provided both in the input data and the database 
record. 

15 First names are compared in obtaining a value for a first name 

match (FNM) criteria. A value of "Y" indicates an exact match including 
equivalent nicknames, abbreviations, and identified misspellings. An exact 
match may also be found where the first letter of the first name, including 
equivalent nicknames and abbreviations, match but only if the input data or the 

20 database record has a first name as an initial. Lastly, an exact match can be 
found if it matches to a nickname table entry. A value of TST indicates that there 
is no match and that a first name is specified in both die input data and die 
database record. 

Middle names are compared to yield a value for a middle name 
25 match (MNM) criteria. The MNM criteria may have a value of "Y", which 
indicates an exact match, equivalent nicknames and equivalent abbreviations. A 
value of "N" indicates that there is no match and that a middle name is specified 
in both die input data and die database record. A value of "B" indicates that one 
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or both of the input data in the database record are not populated with a middle 
name. 

Gender is compared in the gender (GDR) matrfrjpg criteria. A 
value of "N" indicates that no match is found between a male, female, or 
5 company genders in both the input data and the database record A value of "A" 
indicates that the input data or the database record is populated with an 
ambiguous gender value. A value of a M n indicates that both the input data and 
the database record are populated with male gender codes. A value of "F* 
indicates that both the input data and the database record are populated with 

10 female gender codes. A value of "C indicates that both sources are populated 
with company gender codes. 

Titles of clients are compared to yield a value for the title (TTL) 
matching criteria. A value of "Y" indicates an exact match on a courtesy title or 
match of equivalent ambiguous values. For example, the abbreviation "Mrs.** 

15 matches "Ms." A value of "N" indicates that there is no match and that both the 
input data and the database record are populated with courtesy titles. A value of 
"B" indicates that the input data or the database record or both are not populated 
with a courtesy title. 

Zip codes are compared to yield the value for a zip code matching 

20 criteria (ZIP). A value of "9" indicates an exact match of a full nine-digit zip 
code. A value of "7" indicates a match on the first seven digits of a zip code. A 
value of u 5" indicates a match on the first five digits of a zip code A value of 
TST indicates no match and that both the input data and the database record are 
populated with zip codes. 

25 Street names and street suffixes are compared in the street names 

and street suffixes (STR) matching criteria. A value of "Y" indicates an exact 
match of street names and street suffixes. A value of "N" indicates no match and 
that both the input data and the database record are populated or that one of these 
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two is not populated. A value of "B" indicates that both the input data and the 
database record are not populated with a street name or a street suffix. 

An address number or P.O. Box number is compared to yield the 
value for die number (NBR) matching criteria. A value of a Y" indicates an exact 
5 match. A value of "N" indicates no match and that both the input data and the 
database record are populated by the same type of information. 

Apartment numbers are compared to yield the value for the 
apartment (APT) matching criteria. A value of "Y" indicates an exact match. A 
value of "N" indicates that there is not a match and that both the input data and 
10 the database record contain an apartment number specification. A value of "B" 
indicates that the input data or the database record is not populated with an 
apartment number. 

Phone numbers are compared to yield a value for die phone number 
(PHN) matching criteria. A value of "Y" indicates an exact match of phone 
15 numbers. A value of "hF indicates that there is not a match and that both the 
input data and the database record contain phone numbers. A value of "B" 
indicates that either the input data or the database record do not contain a phone 
number. 

Account numbers are compared to yield the value for die account 
20 number (ACC) matching criteria. A value of "Y" indicates an exact match where 
both the input data and the database record are populated with an account 
number. A value of *T S T indicates that die input data and the database record 
contain account numbers and that there is no match between the account 
numbers. A value of "B" indicates that one or both of the input data and the 
25 database record are not populated with an account number. 

Membership numbers are compared to yield a value for the 
membership number (MEM) criteria. A value of "Y" indicates an exact match 
on a specific membership number. A value of "N" indicates that there is no 
match and that both die input data and the database record are populated with the 
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same type of membership number. A value of indicates that one or both of 
die input data and die database record are not populated with the membership 
number. 

ClienMd's may be compared to yield a value for the client_id 
5 matching criteria. A value of "Y" indicates an exact match where both the input 
data and the database record are populated with client_ids. A value of T 
indicates that there is no match and that both the input data and the database 
record are populated with client Jds. A value of"B" indicates that one or both of 
the input data and the database record are not populated with a client ID. 
10 It should be noted that each of these matching criteria may also 

assume a value of indicating that the determination of whether there is a 
match or not is not dependent upon that criteria. 

The values are utilized by applying match rules using a match rule 
tables to determine if there is a match (step 136 in Figure 6). An example of 
15 match rule is as follows: 
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1 = SSN 2 = LNM 3 =FNM 4 = MNM 5 = GDR 6 = TTL 
7 = ZIP 8 = STR 9 = NBR 10 = APT 
11=PHN 12 = ACC 13 = MEM 14 = CLN 



Each row within the match rule table contains a scenario and a 
20 result (note the columns labeled "scenario" and "result-rule"). Each row may be 
considered a separate rule. Each other column specifies a particular value for 
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one of the 14 match criteria described above (see the Legend above). If the 
criteria have the value specified in the columns, then the rule is fulfilled and the 
result of the rule is applied. For example, scenario 1 13 specifies that if there is a 
last name match (column 2 is M Y"), there is a first name match (column 3 is 
5 "Y"), Acre is a middle name match (column 4 is "Y"), both the input data and 
the database record are populated with male gender codes (column 5 is "NT), one 
or both the sources are not populated with a courtesy title (column 6 is "IT), 
there is a zip code match (column 7 is tt Y"), there is a street name and street 
name suffix match (column 8 is "Y"), there is a number match (column 9 is "Y") 
10 and there is an apartment match (column 10 is "Y"), it is determined that the 
input data and the database record match. As a result, a determination is made in 
step 126 of Figure 5 of whether there is a match or not by applying the match 
rule tables. 

It should be appreciated that there are a number of different 
15 combinations or scenarios within the match rule table that could be categorized 
into the categories set forth in Figure 7. In particular, the match rule table 
contains the following combinations: name and address combinations 140, name 
and phone combinations 142, name and social security number combinations 
144, name and account combinations 146, name and membership number 
20 combinations 148, name and client ID combinations 150, address and phone 
combinations 152, address and account combinations 154, address and 
membership number combinations 156, phone and account combinations 158, 
phone and membership number combinations 160, and account and membership 
number combinations 162. 
25 If it is determined in step 126 that there is not a match between the 

input data and any database records that hold client profiles, a new record may 
be created and a new client identifier is assigned to the client (step 128 in Figure 
5). The new record is filled in with the data that is provided in the input data that 
has been processed by the stage load process 102. 
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In contrast, if a match is found, an overlay process is applied to 
determine how to resolve the conflict between the client information contained in 
the input data and the client database record (step 130 in Figure 5). In general, as 
will be described in more detail below, the overlay process applies overlay rules 
5 and resolution rules to determine how to resolve the conflicts and the data is 
updated accordingly within the client database 56 (step 132 in Figure 5). This 
overlay process is depicted as overlays 1 14 in Figure 4 and results in data that is 
passed to the client database 56. 

Figure 8 depicts different varieties of overlay rules 164 that are 

10 provided by CARMA 12. There are client overlay rules 166. The general 
approach of die client overlay rules is after receiving an indication that there is a 
match, the name fields in the client database 56 are only updated if the input data 
has more complete information. The client overlay rules contain specific rules 
directed to fields in the client table 60. The active address overlay rules 168 

15 specify how active address information within the client database 56 should be 
overlaid relative to input data that matches. The informational address overlay 
rules 170 specify how informational address information should be overlaid. The 
phone number overlay rules 172 specify how phone number information should 
be overlaid. The enhancement overlay rules 174 specify how enhancements 

20 should be overlaid. The list specific database table overlay rules specify what 
database tables are allowed to be updated for any specific load feed. Lastly, the 
client_provider_detail overlay rules indicate how client provider information in 
the database 56 should be overlaid. 

Once a client database 56 has been updated, the changes may be 

25 replicated by a client database replication process 1 16 and may be passed on to a 
data harvesting facility for an operational data store managed by the DSS 20. 
Changes are captured by a changed data capture process 118 that forwards the 
changes to the data, harvesting process 96 of the data warehouse of DSS 20. 
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Therefore, CARMA 12 provides an integrated system for client 
profile management that provides a number of unique features. CARMA tracks 
individual clients as individuals for other than as telephone numbers or addresses 
so that multiple clients that share telephone numbers or addresses may be 
5 tracked CARMA 12 maintains multiple relationships, including multiple 
addresses per client and multiple phone numbers per client. This facilitates 
complete tracking of clients having multiple phone numbers or addresses. 
CARMA 12 provides continuous ongoing tracking of clients and readily 
facilitates changes to client profiles. CARMA 12 includes processing resources 

10 for accepting and using input data of almost any type in any format. Still further, 
CARMA performs effective client matching to avoid duplicate client profiles. 

While the present invention has been described with reference to a 
preferred embodiment thereof those skilled in the art will appreciate that various 
changes in form and detail may be made without departing from the intended 

15 scope of the present invention as defined in the appended claims. 
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CLAIMS 

1. In a computer system having a database holding client profiles 
that each hold information regarding clients for marketing contact, a method 
comprising the computer-implemented steps of: 

receiving input data holding data about a client from a data provider for 
possible addition to the database; 

applying matching rules that determine whether die input data is for a 
selected client that already has a client profile in the database, wherein the matching 
rules compare any name information and any address information in the input data 
with any name information and any address information in the client profile for the 
selected client; 

if it is determined by the matching rules that the input data is not for a 
selected client that already has a client profile in the database, creating a new client 
profile for the selected client in the database to hold data from the input data; 

if it is determined by the matching rules that the input data is for a 
selected client that already has a client profile in the database, applying overlay rules 
to determine how to update the client profile in the database for the selected client in 
view of the input data; and 

updating the client profile in the database based on how it was 
determined to update the client profile in the database by applying die overlay rules. 

2. The method of claim 1 wherein the matching rules compare any 
social security number information in the input data and with any social security 
information in the client profile for the selected client. 

3. The method of claim 1 wherein the matching rules compare any 
phone numbers in die input data with any phone numbers in the client profile for the 
selected client. 
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4. The method of claim 1 wherein the matching rules compare any 
account numbers in the input data with any account numbers in the client profile for 
the selected client 

5. The method of claim 1 wherein the matching rules compare any 
membership numbers in the input data with any membership numbers in the client 
profile for the selected client 



6. The method of claim 1, further comprising the step of formatting 
the input data into a standard format prior to applying the matching rules. 

7. The method of claim 6, further comprising the step of applying 
data hygiene rules to remove unwanted data in the input data prior to applying the 
matching rules. 

8. The method of claim 1, further comprising the step of applying 
data hygiene rules to remove unwanted data in the input data prior to applying the 
matching rules. 

9. A computer-readable medium holding computer-executable 
instructions for performing a method comprising the computer-implemented steps of: 

receiving input data holding data about a client from a data provider for 
possible addition to die database; 

applying matching rules that determine whether the input data is for a 
selected client that already has a client profile in die database, wherein the matching 
rules compare any name information and any address information in the input data 
with any name information and any address information in the client profile for the 
selected client; 
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if it is determined by the matching rules that the input data is not for a 
selected client that already has a client profile in the database, creating a new client 
profile for the selected client in the database to hold data from die input data; 

if it is determined by the matching rules that die input data is for a 
selected client that already has a client profile in the database, applying overlay rules 
to determine how to update the client profile in the database for the selected client in 
view of the input data; and 

updating the client profile in the database based on how it was 
determined to update die client profile in the database by applying die overlay rules. 

10. In a computer system, a method comprising the computer- 
implemented steps of: 

providing a database for storing client profiles for marketing contact 
wherein each client profile stored information regarding a client; 

storing a first client profile for a first client at a given telephone number 
in the database; 

storing a second client profile for a second client at die given telephone 
number in the database; and 

indexing the database for accessing the client profiles on a per client 

basis. 

1 1. The method of claim 10, further comprising the steps of receiving 
a request to access die first client profile and granting access to the first client profile 
in response to the request. 

12. In a computer system, a method comprising the computer- 
implemented steps of: 

providing a database for storing client profiles for marketing contact 
wherein each client profile stores information regarding a client; 
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storing a first address in the database for a selected client in a client 
profile for the selected client; 

storing a second address in the database for the selected client in the 
client profile for the selected client; and 

in response to a request from a requester, providing one of the first 
address and the second address for the selected client to die requester. 

13. The method of claim 12 wherein the method further comprises 
the step of storing a first phone number in the database for a given client in a given 
client profile for the given client and storing a second phone number in the database 
for die given client in die given client profile. 

14. In a computer system having a database holding client profiles 
that hold information regarding clients for marketing contact, a method comprising the 
computer-implemented steps of: 

receiving a first set of input data in a first format from a first data 

provider; 

reformatting the first set of input data into a standardized format; 

adding at least some of the data in the first set of input data to a first 
client profile in the database; 

receiving a second set of input data in a second format from a second 
data provider, 

reformatting the second set of input data into the standardized format; 

and 

adding at least some of the data in the second set of input data to a 
second client profile in the database. 

15. The method of claim 14 wherein the first format and the second 

format differ. 
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16. The method of claim 14 wherein die first set of input data 
contains data of different data type than data found in die second set of input data 

17. The method of claim 15 wherein the first data provider is external 
to the computer system. 
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